\chapter{Gestion de la configuration et des modifications}
\label{chap:gestion.configuration}
\minitoc

\section{Gestion de la configuration}

La configuration est l'ensemble des \'el\'ements suivants : code source ex\'ecutable, 
outils de d\'eveloppement et de test utilis\'es, documents et donn\'ees.


%-------------------------------------%

\subsection{Outils de travail collaboratif}
Voici les outils que nous utiliserons pour g\'erer le travail collaboratif :

\begin{description}
 \item[Subversion] :

Cet outil permet de partager le code source d'un logiciel et d'int\'egrer facilement 
les modifications de fichiers d'un d\'eveloppeur avant de les mettre \`a disposition des autres utilisateurs.
Cet outil permet \'egalement de garder un historique de toutes les modifications et des diff\'erentes versions du projet. 
Il permet ainsi de revenir \`a une version pr\'ec\'edente en cas de probl\`eme.

 \item[Mailing lists] :

L'inscription aux mailing lists des projets associ\'es est essentielle pour prendre 
en main les outils, participer aux discutions et \^etre au courant des nouvelles versions et des corrections
 d'erreurs. 

Nous sommes inscrits comme d\'eveloppeur (committer) des projets JOnAS et JASMINe.



 \item[JIRA] :

Pour le suivi des bugs ainsi que les  \'evolutions majeures, JIRA\footnote{http://www.atlassian.com/software/jira/} est utilis\'e. On peut de
cette mani\`ere avoir une trace pr\'ecise des probl\`emes rencontr\'es et leur contexte, mais \'egalement
des informations sur les d\'eveloppeurs les ayant corrig\'es.


 \item[Bamboo] :

      Les projets  \'evoluant quotidiennement et chaque d\'eveloppeur ayant un environnement de travail
particulier, il est n\'ecessaire de tester la compilation sur une machine ``neutre'' r\'eguli\`erement. C'est
pourquoi une machine d\'edi\'e \`a cette activit\'e est accessible et administrable via Bamboo\footnote{http://www.atlassian.com/software/bamboo/}  , et effectue
une mise \`a jour des projets et une compilation compl\`ete \`a chaque changement de r\'evision (commit).


 \end{description}

%-------------------------------------%

\subsection{Environnement technique}
Le d\'eveloppement sera effectu\'e indiff\'eremment sous environnement Linux (Debian) ou Windows XP, 
le projet \'etant en enti\`erement en langage Java et Flex.

%-------------------------------------%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Gestion des modifications}

\subsection{Proc\'edure de modification}

Les modifications peuvent avoir deux origines : 
\begin{itemize}
\item D\'etection d'une anomalie
\item Demande d'\'evolution
\end{itemize}

Dans le premier cas, il faut trouver la source de l'anomalie puis la corriger dans les plus brefs d\'elais. 
Le plus souvant, chaque anomalie est associ\'ee avec un ``issue'' ou un ``bug'' dans la plate-forme JIRA.
L'issue a un num\'ero d'ordre de type ``MONITORING-XY''.
Chaque message du commit doit \^etre prefix\'e de ce num\'ero, afin de bien pouvoir identifier la source
du commit.

Dans le second cas demande d'\'evolution du logiciel par le client, il faut, dans un premier temps, r\'ealiser une \'etude de faisabilit\'e pour ensuite modifier le logiciel en cons\'equence si cela s'av\`ere r\'ealisable dans les d\'elais impartis.
Les membres du MOEd sont responsables de la mise en \oe uvre de ces modifications.

%-------------------------------------%
\subsection{R\`egles d'\'evolution des num\'eros de version du logiciel}

Les applications sont identifi\'es par un num\'ero de version, un num\'ero de r\'evision et un num\'ero de correction comme suit : 
``Num\'eroVersion.Num\'eroR\'evision.Num\'eroCorrection''.
Trois cas peuvent n\'ecessiter un changement de version.
\begin{description}
 \item[Une nouvelle livraison de l'application :] 

On incr\'emente le num\'ero de version. Les num\'eros de r\'evision et de correction 
reviennent \`a z\'ero.
 \item[Une \'evolution :] 

On incr\'emente le num\'ero de r\'evision. Le num\'ero de correction revient \`a z\'ero.
 \item[Une correction d'anomalie(s) :] 

On incr\'emente le num\'ero de correction.
 \end{description}

%-------------------------------------%
\subsection{R\`egles d'\'evolution du statut}
Pour chaque document, un statut doit \^etre mentionn\'e. Celui-ci peut-\^etre :
\begin{description}
 \item[Initial :] le document est en cours de r\'edaction, il n'est pas diffusable, m\^eme en interne.
 \item[Diffusable :] le document est r\'edig\'e, il peut \^etre diffus\'e en interne mais il n'a pas encore \'et\'e valid\'e.
 \item[Final :] le document a \'et\'e valid\'e. Il peut \^etre consult\'e ou livr\'e.
 \end{description}
%end Gestion_config.tex